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Abstract. A protocol-independent secrecy theorem is established and 
applied to several non-trivial protocols. In particular, it is applied to 
protocols proposed for protecting the computation results of free-roaming 
mobile agents doing comparison shopping. All the results presented here 
have been formally proved in Isabelle by building on Larry Paulson's 
inductive approach. This therefore provides a library of general theorems 
that can be applied to other protocols. 

1 Introduction 

Cryptographic protocols are intended to ensure properties like secrecy, authenti- 
cation, anonymity, integrity or non-repudiability. Initially proposed for securing 
communications, they have been more recently proposed for protecting the com- 
putation results of free-roaming mobile agents doing comparison shopping |2bJ . 
Experience shows that even simple protocols are difficult to set correctly |14j . 
Their correctness clearly needs to be checked by mechanical tools. But this can- 
not be an easy task. For instance, secrecy has been shown undecidable even 
under very weak assumptions And correctness is always with respect to a 
given model. A protocol correct in a model may be incorrect in a richer model 
\2'6\ . As for the effectiveness of cryptography, which is often assumed perfect 
in the formal versions of protocols, fortunately, it may be precisely related to 
the one of real protocols Although we cannot expect formal methods to be 
able to deal with every possible problem (like [25] for instance), yet they provide 
better confidence and may serve in finding protocol-specific flows. 

Many different approaches have been proposed so far. Approaches based on 
mo del- checking are quite effective but the state explosion forces the model to 
be kept simple, typically by limiting the number of agents and other param- 
eters to one or two although, in some cases, checking can be done in a finite 
model Approaches based on proof assistants allow a finer and more gen- 
eral modelization but require much effort, typically of several days or weeks, 
although the use of automated theorem provers may be very effective too 
Proof-assistants (Isabelle ^H], PVS etc.) can establish protocol-independent 
theorems whose conditions could be proved by means of specialized automatic 



tools, providing a really complete certification. In this spirit, Millen and Rucfi 
formalized a protocol-independent secrecy theorem |TH] in PVS ^jl and later 
developed with Cortier an automatic proof search procedure [7J . 

In this paper, we develop in Isabelle a more general secrecy theorem based 
on Paulson's inductive approach |21j . which has several advantages over the 
previous approach. First, we require no additional information (spell or state 
events) in order to be more general and also compatible with the libraries already 
implemented in Isabelle by Paulson and Bella. Second, we establish a first secrecy 
theorem (Section [3]) which only involves the Isabelle theory of messages, and 
thus is independent of any protocol formalization. It is based on the simple and 
intuitive notion of guarded messages which, as opposed to the notion of coideal 
used in JS], distinguishes between what must be kept secret (a key or a nonce m) 
from how this secret is ensured (the set iKs of the keys whose inverses are used 
for encrypting m). It simply says that, if someone can get m by decomposing 
and decrypting a set of guarded messages, then he must also be able to get one 
of the key of iKs. Therefore, if the keys of iKs are not compromised, then the 
spy cannot get m. 

Then, we establish a second theorem (Section 0J) showing that, for proving 
the guardedness of a nonce or a key m used in a protocol, and hence that m is 
kept secret, it is sufficient to prove that each rule of the protocol indeed preserve 
the guardedness of in, without having to care about what the spy can do (which 
is taken into account once and for all in the proof of the theorem). This departs 
from proofs in strand spaces JUj or with coideals [7] where it is necessary to step 
back into the protocol rules, including the rules for the spy, in order to explore 
every possibility of how certain message fields could have been published. 

We applied our results to several well-known protocols: Needham-Schoeder- 
Lowe |17ll4j . Otway-Rees JH] and Yahalom pQ. We also verified two protocols 
proposed by Asokan, Giilcii and Karjoth |2- for protecting the computation re- 
sults of free-roaming mobile agents doing comparison shopping. These have never 
been formally certified before. The properties claimed by the authors (see Sec- 
tion |SJ not only include confidentiality properties but also non-repudiability and 
integrity properties. This shows a new application of Isabelle. 

The paper is organized as follows. In Section [2 we quickly present Paulson's 
inductive approach |21| . In Section we present our notion of guarded message 
for proving secrecy. In Section 21 we introduce a more precise formalization of 
protocols and show how it helps to prove guardedness. In Section [3 we present 
the protocols PI and P2 proposed in [2] for protecting the computation results 
of free-roaming agents. In Section we explain the formal proof of their cor- 
rectness. 

All the Isabelle files are freely available on our web page. 
2 Paulson's inductive approach 

The inductive approach has been introduced by Paulson |21| and applied to many 
non-trivial protocols within the generic proof assistant Isabelle [IS] : Kerberos IV 



3 1, TLS H2, SET 120], etc. All these results are part of the Isabelle distribution 
and can be freely used to certify other protocols. 

In this approach, a protocol is represented as the set of all the possible 
sequences of events that can occur by following the protocol steps and by having 
a spy able to send fake messages built from the analysis of past traffic. An infinite 
number of agents is assumed: 

datatype agent = Server I Friend nat I Spy 

Messages are represented as the elements of the following inductive data type: 

datatype msg = Number nat (* guessable *) I Nonce nat (* not guessable *) 
I Agent agent I Key nat I Hash msg I {|msg, msg|} I Crypt key msg 

This has several important consequences: 

• Encryption is assumed to be perfect: decryption can only be done by using 
the inverse of the key used for encryption. Within a public-key infrastructure, 
the inverse of the public key of an agent iA, lpubK A, is its private key lpriK 
A. Otherwise, each agent iA is assumed to have a symmetric key ishrK A 
whose inverse is itself. 

• Hashing is collision-free: two distinct messages give two distinct hash codes. 
This comes from the fact that the constructors of an inductive data type are 
injective. 

• Each kind of message is recognizable and hence cannot be confused with 
another one: an agent name lAgent A is distinct from a key iKey K or an 
encrypted message lCrypt K X, etc. This comes from the fact that the con- 
structors of an inductive data type have distinct images. This implies that 
encryption schemes for which there are relations between encrypted messages 
like XOR (lCrypt K (Crypt K X) = X) or RSA (lCrypt K (Crypt K' X) = 
Crypt K' (Crypt K X)) cannot be formalized. 

Then, Paulson introduces three important functions: 

• The function lparts H returns the set of all the actual sub-components of a 
set iH of messages (lX is not a sub-component of lHash X) : 

consts parts : : "msg set =>- msg set" 

inductive "parts H" intros 

Inj : "X G H ==> X G parts H" 

Fst: "{|X,Y|} G parts H ==> X G parts H" 

Snd: "{|X,Y|} G parts H => Y G parts H" 

Body: "Crypt K X G parts H =>■ X G parts H" 

• The function lanalz H returns the set of all the sub-components that can be 
obtained by decomposing and decrypting (if the necessary key has itself been 
obtained) all the messages of the set iH: 

consts analz : : "msg set => msg set" 

inductive "analz H" intros 

Inj : "X G H ==> X G analz H" 

Fst: "{|X,Y|} G analz H X G analz H" 

Snd: "{|X,Y|} G analz H ==> Y G analz H" 



Decrypt: "[Crypt K X G analz H; Key(invKey K) G analz H] 
=> X £ analz H" 

• The function lsynth returns the set of all the messages that can be synthesized 
from a set iH of messages (new nonces and new keys cannot be synthesized): 
consts synth : : "msg set => msg set" 
inductive "synth H" intros 
Inj : "X G H => X G synth H" 
Agent: "Agent agt G synth H" 
Number: "Number n G synth H" 
Hash: "X G synth H Hash X G synth H" 

Pair: "[X G synth H; Y G synth H] =>■ {|X,Y|} G synth H" 
Crypt: "[X G synth H; Key K G H] => Crypt K X G synth H" 

Finally, the fact that an agent iA sends to another agent iB a message iX is 
represented by the event iSays A B X. 

As an example, we give the formalization of the Needham-Schroeder-Lowe 
protocol |14| : 

1. A->B : {Na, A} Kb 

2. B -> A : {Na,Nb,B} Ka 

3. A^B: {Nb} Kb 

consts nsl : : "event list set" 
inductive nsl intros 
Nil: " [] G nsl" 

Fake: "[evs G nsl; X G synth(analz(spies evs))] 
=>■ Says Spy B X # evs G nsl" 

NS1: "[evs G nsl; Nonce NA ^ used evs] 

=>■ Says A B (Crypt (pubK B) {|Nonce NA, Agent A|}) # evs G nsl" 

NS2: "[evs G nsl; Nonce NB £ used evs; 

Says A' B (Crypt (pubK B) {|Nonce NA, Agent A|}) G set evs] 

=>■ Says B A (Crypt (pubK A) -|]Nonce NA, Nonce NB, Agent B|}) # evs G nsl" 

NS3: "[evsG nsl; Says A B (Crypt (pubK B) {|Nonce NA, Agent A|}) G set evs; 
Says B> A (Crypt (pubK A) {|Nonce NA, Nonce NB, Agent B|}) G set evs] 
==> Says A B (Crypt (pubK B) (Nonce NB)) # evs G nsl" 

The first two rules are in any protocol. iNil means that the empty trace i[] 
is in the protocol. lFake means that the spy can send fake messages built from 
the analysis of past traffic. The next rules are the rules of the protocol, lset evs 
is the set of all the messages sent so far. lused evs denotes the parts of all the 
messages sent so far. lev # evs is the list of head lev and tail levs. 

Then, one may prove for example that, if iB sends the message of step 2 
and receives the message of step 3, and if the private keys of iA and iB are not 
compromised (iA and iB do not belong to the set ibad of bad agents) , then the 
protocol must have been initiated by iA: 

lemma "[A ^ bad; B ^ bad; evs G nsl; 

Says B A (Crypt (pubK A) {|Nonce NA, Nonce NB, Agent B|}) G set evs; 



Says A' B (Crypt (pubK B) (Nonce NB) ) G set evs] 

=> Says A B (Crypt (pubK B) {|Nonce NA, Agent A|}) G set evs" 

As most authentication properties, it relies on the fact that the nonces used 
by the agents and encrypted with their public keys are not known by the spy: 
lemma "[A £ bad; B ^ bad; evs G nsl; 

Says A B (Crypt (pubK B) {|Nonce NA, Agent A|}) G set evs] 
=> Nonce NA ^ analz(spies evs)" 

This is why, in the following, we concentrate on secrecy proofs. 
3 Guarded messages 

The idea of the protocol-independent secrecy theorem is simple and intuitive. In 
any protocol, secrecy is ensured by using cryptography and by making sure that 
the key used for the encryption is indeed safe. We simply turn this into a formal 
definition, the notion of guarded message, and formally prove that getting the 
secret indeed requires to know the key used for encryption (normally safe). 

Definition 1 (Guarded messages). A nonce or a key in is guarded in a 
message iX by a set of keys iKs if every occurrence of m in iX is inside a sub- 
message encrypted by the inverse of a key of iKs. We denote by iguard n Ks the 
set of messages in which in is guarded by iKs. 

consts guard : : "nat =>• key set => msg set" 
inductive "guard n Ks" intros 

No_Nonce: "Nonce n ^ parts X X G guard n Ks" 

Guard: "invKey K G Ks Crypt K X G guard n Ks" 

Crypt: "X G guard n Ks => Crypt K X G guard n Ks" 

Pair: "[X G guard n Ks ; Y G guard n Ks] {|X,Y|} G guard n Ks" 

The secrecy theorem can then be stated as follows: 

Theorem 2 (Secrecy). Let iG be a set of messages where iNonce n is guarded 
by a set of keys iKs. If iNonce n belongs to lanalz G then there exists a key iK 
in iKs that belongs to lanalz G: 

theorem Guard_invKey : "[Nonce n G analz G; Guard n Ks G] 
=> 3 K. K G Ks & Key K G analz G" 

Proof. Although this result may seem obvious, it is not straightforward to prove 
in Isabelle or in any other proof assistant. We explain how our formal proof 
proceeds. 

First, only a finite part of iG needs to be analyzed to get iNonce n. Therefore, 
we can assume that iG is finite. We then associate to any finite set iG a measure 
^i(iG) which is the number of encrypted messages in iG We can then reason by 
induction on ^t(iG). 

Second, to help reason about lanalz, we proved the following very useful 
decomposition theorem: lanalz G = lpparts G U lanalz (lkparts G), where lpparts 



G is all the pairs of iG, their components that are themselves pairs and so on, 
and ikparts G is all the components that are not pairs. 

Now, since all the messages in iG are guarded, to get iNonce n, there must 
be an encrypted message lCrypt K Y in ikparts G such that iKey (linvKey K) 
belongs to ikparts G also: we must decrypt at least one encrypted message for 
reaching iNonce n. If iK is a key of iKs then we are done. Otherwise, let iH = 
ikparts G \ {lCrypt K Y}. Then, by definition of lanalz, iNonce n must belong 
to lanalz (iH U {iY}) whose measure is strictly smaller than the one of iG. 
Therefore, we can conclude by induction hypothesis. □ 

Our notion of guardedness has several advantages over the notion of coideal 
of Millen and RueB |15|. First, it is defined inductively while a coideal is defined 
as the complement of an ideal [5] (which is defined inductively). Second, it is 
more general in the sense that the coideal of {iNonce n} U iKs is included in 
iguard n Ks but not the converse. For instance, while iKey K is guarded by {iK} 
in lCrypt (linvKey K) (iKey K), it does not belong to the coideal of {iK}. This 
is due to the fact that there is no separation between what must be kept secret 
(in in iguard n Ks) and how it must be kept secret (iKs in iguard n Ks). Third, 
guardedness enjoys a nice monotonicity property: 

lemma guard_extend: "Ks C Ks' => guard n Ks C guard n Ks'" 

which is very useful in the case of protocols like Yahalom where a nonce must 
be guarded by a session key issued by a server (see below). This is not the 
case with coideals. For instance, {|iCrypt (lpubK A) (iNonce n), iKey K|}, in 
which iNonce n is guarded by {iNonce n, priK A}, hence by {iNonce n, priK A, 
Key K} too, belongs to the coideal of {iNonce n, priK A} but not to the coideal 
of {iNonce n, priK A, Key K}. So, guardedness is a finer and more intuitive 
notion than the one of coideals. 

In the case of the Needham-Schroeder-Lowe protocol, one can formally prove 
that iNA and iNB are both guarded by i{priK A, priK B}. Therefore, after our 
theorem, if the private keys of lA and iB are not compromised then the spy 
cannot have access to iNA and iNB. 

lemma Guard_NA: "[evs G nsl; A ^ bad; B <f_ bad; 

Says A B (Crypt (pubK B) {|Nonce NA, Agent A|}) G set evs] 

==> Guard NA {priK A, priK B} (spies evs)" 
lemma Guard_NB: "[evs G nsl; A ^ bad; B <f_ bad; 

Says B A (Crypt (pubK A) {|Nonce NA, Nonce NB, Agent B|}) G set evs] 

=> Guard NB {priK A.priK B} (spies evs)" 

We applied our theorem to other well known protocols: the Otway-Rees sym- 
metric-key protocol \Fij\ an d the Yahalom symmetric-key protocol PP . By doing 
so, we noticed a much shorter development time compared with the direct proofs 
done by Paulson [21]. Of course, this is not as fast as automatic tools like TAPS 
[5] but we expect to define tactics to automate these guardedness proofs. 

The Yahalom protocol is interesting since it is a simple case of dependency 
between secrets [22]. We recall the informal definition of the protocol (S denotes 
the server): 



1. A -» B : A,Na 

2. B -> 5 : £?, {A, iVa, Nb}Kb 

3. 5 -» A : {B, K, Na, Nb} Ka , {A, K} Kb 
A.B^A:{A,K} Kb ,{Nb} K 

One can prove that the session key iK is guarded by the keys of iA and iB, 
and that the nonce iNB is guarded by the keys of iA and iB and all the session 
keys issued by the server: 

lemma Guard_KAB : "fevs G ya; A bad; B <f_ bad; 

Says Server A {Crypt (shrK A) {|Agent B, Key K, Nonce NA, Nonce NB|}, 

Crypt (shrK B) {|Agent A, Key K|}|} G set evs] 

=> Guard K {shrK A, shrK B} (spies evs)" 
lemma Guard_NB: "[evs G ya; A ^ bad; B ^ bad; Says B Server 

{|Agent B, Crypt (shrK B) {|Agent A, Nonce NA, Nonce NB}|} G set evs] 

=> Guard NB ({shrK A, shrK B} U keys A B NA NB evs) (spies evs)" 
keys A B NA NB evs = {K. Says Server A {Crypt (shrK A) {Agent B, Key K, 

Nonce NA, Nonce NB|}, Crypt (shrK B) {Agent A, Key K|}|} G set evs} 

In our formalization, the server may issue several session keys for the same 
request by repeating step 3. This may be avoided by checking whether step 3 
has already been done. Note also that the set of keys iKs used here takes care of 
two different states of the protocol: if no session key has been issued yet then, 
indeed, only the keys of iA and iB are sufficient for protecting iNB. 

4 Guardedness proofs 

In order to ease guardedness proofs, we have developed other theorems inspired 
by the work of Millen and Ruefi (TJ|. The idea is to reduce the proof for all 
possible traces to a proof that all the protocol rules preserve the guardedness 
condition. This requires to introduce a more precise formalization of the notion 
of protocol. 

Definition 3 (Protocol rule). A message pattern is a message with variables 
of distinct types for agents, nonces, keys, etc. Event patterns are defined simi- 
larly. A substitution is is an application which associates an agent to each agent 
variable, a nonce to each nonce variable, etc. Replacing each variable of a mes- 
sage pattern iX by its image in a substitution is gives a message denoted by mpm 
s X. For an event pattern lev, the substitution is denoted by lap s ev. 

A rule iR is a pair made of a set of event patterns ifst R, the preconditions, 
and an event pattern isnd R. The set of new nonces of a rule iR, mewn R, is 
the set of nonce variables that occur in isnd R and in no precondition. 

Now, a protocol will be seen as a set of rules: 

types proto = "(event set * event) set" 

Then, the traces generated by a protocol are inductively defined as follows: 

consts tr : : "proto => event list set" 
inductive "tr p" intros 



Nil: " [] G tr p" 

Fake: "[evs G tr p; X G synth(analz (spies evs))] 

==> Says Spy B X # evs G tr p" 
Rule: "[evs G tr p; R G p; ok evs R s] =>■ ap s (snd R) # evs G tr p" 

An ls-instance of a rule iR can be added to a trace levs if the ls-instance of 
every precondition occurs in levs and the ls-instance of every new nonce has not 
been used yet: 

ok evs Rs=(Vx. xGfstR > ap s x G set evs) 

k (V n. n G newn R > ap s n $5 used evs) 

Definition 4 (Freshness). We will denote by ifresh R' s' n Ks evs the fact 
that a nonce in is introduced in a trace levs by an is '-instance of a rule iR ' in 
which it is guarded by a set of keys iKs. 

Theorem 5 (Guardedness). Assume that all the rules of the protocol preserve 
the guardedness of in w.r.t. iKs if the keys of iKs are safe: 

preserv p n Ks = V evs R' s' R s. evs G tr p > fresh R' s' n Ks evs 

> Guard n Ks (spies evs) > safe Ks (spies evs) 

> ok evs R s > ap s (snd R) G guard n Ks 

safe Ks (spies evs) = V K. K G Ks ► K ^ analz (spies evs) 

Then, if in is also guarded in the initial knowledge of the spy, we get that in 
is guarded in every possible trace: 

theorem preserv_Guard : "[preserv p n Ks; evs G tr p; fresh R' s' n Ks evs; 
safe Ks (spies evs); Guard n Ks (init Spy)] ==> Guard n Ks (spies evs)" 

4.1 Examples 

As an example, let us see the case of the Otway-Rees protocol |19j : 

1. A -► B : {Na, A, B, {Na, A, B} Ka } 

2. B^S: {Na, A, B, {Na, A, B} Ka , {Na, Nb, A, B} Kb } 
S.S^B: {Na, {Na, K} Ka , {Nb, K} Kb } 

4. B^A:{Na,{Na,K} Ka } 

The formal definition of the rules are: 

0R1 = ({}, 

Says A B flNonce NA, Agent A, Agent B, 

Crypt (shrK A) {|Nonce NA, Agent A, Agent B|}|}) 

0R2 = ({Says A' B {|Nonce NA, Agent A, Agent B, X|}}, 
Says B Server flNonce NA, Agent A, Agent B, X, 
Crypt (shrK B) flNonce NA, Nonce NB, Agent A, Agent B|}|}) 

0R3 = ({Says B' Server flNonce NA, Agent A, Agent B, 
Crypt (shrK A) flNonce NA, Agent A, Agent B|}, 
Crypt (shrK B) flNonce NA, Nonce NB, Agent A, Agent B|}|}}, 
Says Server B flNonce NA, Crypt (shrK A) flNonce NA, Key KAB|}, 
Crypt (shrK B) flNonce NB, Key KAB[j-|}) 



0R4 = ({Says B Server {|Nonce NA, Agent A, Agent B, X, 

Crypt (shrK B) {|Nonce NA, Nonce NB, Agent A, Agent B|}|}, 
Says S B {|Nonce NA, Y, Crypt (shrK B) {|Nonce NB, Key KAB|}|}}, 
Says B A {|Nonce NA, Y|}) 

Let us prove the preservation property. We only detail the case of iNB, the 
case of iNA is similar. Assume that iNB has been introduced by an instance of 
iOR2 and is guarded by {ishrK B}. 

QR1 : Assuming that iNA' is a new nonce, we must prove that iNB is guarded in 
iP = i{|Nonce NA', Agent A', Agent B', Crypt (shrK A') {|Nonce NA', Agent 
A', 

Agent B'|}|}. Since iNA' is new, it cannot be equal to iNB. Guardedness is 
therefore immediate since iNB does not occur in iP. 
0R2: Assuming that iNB' is a new nonce and that iNB is guarded in i{| Nonce 
NA', Agent A', Agent B', X|}, we must prove that iNB is guarded in i{| Nonce 
NA', Agent A', Agent B', X, Crypt (shrK B') {|Nonce NA', Nonce NB', Agent 
A', 

Agent B'|}[}. Again, since iNB' is new, it cannot be equal to iNB. Therefore, 
we are left with the case when iNA' is equal to iNB. But, since iNB is guarded 
in i{|Nonce NA', Agent A', Agent B', X|}, iNA' cannot be equal to iNB and 
we are done. 

0R3: Assuming that iNB is guarded in iP = i{|Nonce NA', Agent A', Agent B', 
Crypt (shrK A') {|Nonce NA', Agent A',Agent B'|}, Crypt (shrK B') {|Nonce 
NA',Nonce NB',Agent A',Agent B'|}|}, we must prove that iNB is guarded in 
iQ = i{|Nonce NA', Crypt (shrK A') {|Noncc NA',Key KAB|}, Crypt (shrK 
B') {|Nonce 

NB', Key KAB|}|}. Since iNB is guarded in iP, iNA' cannot be equal to iNB 
because iNA' is not guarded in iP. Therefore, iNB is guarded in iQ. 
0R4: Assuming that iNB is guarded in i{|Nonce NA',Agent A', Agent B',X, 
Crypt (shrK B') {|Nonce NA', Nonce NB', Agent A', Agent B'[}|} and in 
iP = i{| Nonce NA',Y, Crypt (shrK B') {| Nonce NB', Key KAB|}|}, we must 
prove that iNB is 

guarded in i{|Nonce NA',Y|}. Since iNB is guarded in iP, it cannot be equal 
to iNA' and it is guarded in iY also. Therefore, iNB is guarded in iQ. 

With this protocol, the preservation of guardedness does not require any 
extra property but, in general, it is necessary to have unicity lemmas |21I6| . Let 
us see for instance the Needham-Schroeder-Lowe protocol. Assume that iNA has 
been introduced by an instance of iNSI and is guarded by {ipriK A, priK B}. 
The case of iNB is similar. 

NS1 : Assuming that iNA' is a new nonce, we must prove that iNA is guarded in 
iP = lCrypt (pubK B') {|Nonce NA', Agent A'|}. Since iNA' is new, it cannot 
be equal to iNA. Thus, iNA is guarded in iP. 

NS2: Assuming that iNB' is a new nonce and that iNA is guarded in lCrypt 
(pubK B') {|Nonce NA', Agent A'|}, we must prove that iNA is guarded in 
iP = lCrypt (pubK A') {|Nonce NA', Nonce NB', Agent B'|}. Again, since 



iNB' is new, it cannot be equal to iNA. So, we are left with the case when 
iNA' — iNA. But then, the trace contains two messages: lCrypt (pubK B') 
{(Nonce NA, Agent A'|} and lCrypt (pubK B) {|Nonce NA, Agent A|} for iNA 
has been introduced with iNSl. Since iNA is not known to the spy (the trace 
is assumed to be guarded), this cannot happen: we must have iA = iA' (see 
below). Hence, iNA is guarded in iP. 
NS3: Assuming that iNA is guarded in lCrypt (pubK B') {|Nonce NA', Agent 
A'|} and in lCrypt (pubK A') {|Nonce NA', Nonce NB', Agent B'|}, we must 
prove that it is guarded in iP = lCrypt (pubK B') (Nonce NB'). Assume 
that iNB' = iNA. Then, the trace contains two messages: lCrypt (pubK A') 
{|Nonce NA', Nonce NA, Agent B'|} and lCrypt (pubK B) {|Nonce NA, Agent 
A|} for iNA has been introduced with iNSl. Since iNA is not known to the 
spy, this cannot happen (see below). Therefore, we must have iNB' ^ iNA 
and iNA is guarded in iP. 

To prove the guardedness, we used the following two unicity lemmas, which 
are easily proved: 

lemma "[evs G nsl; Crypt (pubK B) {]Nonce NA, Agent A[j- G parts(spies evs) ; 

Crypt (pubK B') {|Nonce NA, Agent A'[} G parts(spies evs); 

Nonce NA £ analz (spies evs)] =>- A=A' k B=B ' " 
lemma "[evs G nsl; Crypt (pubK B) -(]Nonce NA, Agent A|} G parts(spies evs); 

Crypt(pubK B') {|Nonce NA' , Nonce NA, Agent A'|} G parts(spies evs)] 

=> Nonce NA G analz (spies evs) " 

Similar lemmas hold for iNB. They can be seen as two distinct instances 
of the same unicity lemma: if two rules that should introduce new nonces in 
fact introduce the same nonce in two guarded messages, and if this nonce is not 
known to the spy, then the two messages must be equal. 

4.2 Comparaison with Cortier, Millen and RueB' work 

In |15| , the proof of unicity lemmas is avoided by introducing additional infor- 
mation in the definition of protocols, the spell events, that indicate the nonces 
and keys that must be kept secret and the agents allowed to have access to them, 
and by enforcing the disjointness of spell events. 

The guardedness proofs often follow the same pattern and use the same 
lemmas (that a new nonce is distinct from the nonce for which we want to 
prove the guardedness condition, the unicity lemmas, etc.). We therefore expect 
to turn this into an Isabelle tactic which would try to prove the guardedness 
automatically by using these lemmas. 

Cortier, Millen and RueB [7] define a search procedure for proving a similar 
property, the occultness. But, since it does not take into account the origin of 
a secret (the lfresh predicate in our formalization), it needs to step back into 
the protocol rules and the lFake rule of the spy to get sufficient information for 
concluding, and this may not terminate. Furthermore, they require yet other 
information in the definitions of protocols, the state events, whose usefulness for 
occultness proofs is not clear. 



5 Protocols PI and P2 



As an important and new application, we used our theorem to formally certify 
in Isabelle the correctness of some of the protocols proposed by Asokan, Giilcu 
and Karjoth in |2] for protecting the computation results of free-roaming agents. 
These protocols tolerate collusion between servers and unfixed itineraries. They 
formalize and extend protocols proposed by Yee • Application areas of these 
protocols include comparison shopping, bidding and network routing [SJ. Follow- 
ing the authors, we will use the vocabulary of comparison shopping, hence using 
the word "shop" to denote a server, and the word "offer" to denote the answer 
of a shop to an agent's request. 

These protocols are not concerned with the security problems raised by the 
use of mobile agents: aside from the correctness of the implementations of servers 
and mobile agents, that servers indeed execute the mobile agents code, and that 
servers and agents are indeed protected against malicious agents |26I4I12| . 

The jump of an agent from a server Si to a server S2 can be seen as Si 
sending to S2 a message representing the state of the agent. It therefore fits with 
our model. The difficulty here is that the itinerary is not known a priori: the set 
of servers to be visited can be chosen and extended by the agent itself. This is 
the case when an agent is programmed to go to some information servers which 
may provide it with addresses of shops or other information servers. 

Asokan, Gulcii and Karjoth propose four protocols called PI, P2, P3 and 
P4 depending on the properties one would like and the available infrastructure. 
PI and P2 require a public-key infrastructure. In PI, the author of an offer is 
not kept secret and the integrity of data is publicly verifiable while, in P2, the 
author of an offer can only be known to the owner of the agent. P3 and P4 do 
not assume a public-key infrastructure and use message authentication codes 
(MAC) instead. These last two protocols do not ensure non-repudiability. We 
formally proved all the properties claimed by the authors for PI and P2. We left 
for future work the proof of P3 and P4. 

All the protocols have a common structure: first, the owner of the agent sends 
his agent to the first server and, second, each server receiving the agent sends it 
to the next server after having added his own offer, this last step being repeated 
until the agent comes back to its owner. The difference between the protocols 
lie in the way the messages containing the offers are built. 

For describing the state of the agent in PI and P2, we adopted the message 
format i{|Agent A, Number r, I, L|} where: 

- 1 Agent A is the owner of the agent, 

- iNumber r is the agent's request, 

- ll is the list of servers to be visited, 

- 1L is the list of offers collected so far. 

We choose to send the request and the list of servers to be visited in the clear. 
This is not specified in [5] but we may assume that, in practice, the request is 
implemented as a public data and the itinerary as a private data. However, a 



malicious server executing the agent could easily know about the itinerary, even 
though some encryption is used. So, there is no point in hiding this information. 

On the other hand, we must keep in mind that a malicious server can get 
important information from the itinerary stored in the agent and the way the 
offers are stored also. Indeed, assume that two servers Si and 52 collude. If Si 
sends to 52 the itinerary and the offers of the agent when the agent was at Si , 
then 52 can try to guess to whom belong the offers. As suggested in a way 
to make this more difficult is to shuffle the offers after each new offer. 

Furthermore, even if a server does not try to alter the offers collected so far 
by an agent, it may not give its best offer. Indeed, if it succeeds to know the 
offers collected by the agent so far, it may give an offer which is just a little bit 
better, but not as good as it could. This looks like a Vickery auction (the highest 
bidder pays the second highest bid) but upside-down: the best server offers the 
second lowest price [27?] . 

Then, we formalized PI and P2 as follows: 

consts p : : "event list set" 
inductive p intros 
Nil: " [] G p" 

Fake: "[evs G p; X G synth(analz (spies evs))] 

=> Says Spy B X # evs G p" 
Req: "[evs G p; Nonce n ^ used evs; I G agl] 

==> Says A B (reqm A r n I B) # evs G p" 
Prop: "[evs G p; I G agl; J G agl; Says A' B flAgent A, Number r,I,L|} 

G set evs; isin (Agent C, app (J, del (Agent B, I))); Nonce ofr 

^ used evs] =>■ Says B C (prom B ofr ArPILJC) # evs G p" 

iNil and lFake are the usual rules for the empty trace and the spy respectively. 
iReq corresponds to the first step, the sending of the agent by its owner. We use 
an unguessable message, iNonce n, to identify the session. lProp corresponds to 
the second step, the addition of an offer by a server. The offer is represented 
by an unguessable nonce, iNonce ofr. lagl is the subset of messages representing 
lists of agents, hsin (Agent C, app (J, del (Agent B, I))) means that the next 
server iC is picked among the agents of il, except the first occurrence of iB, or 
among a new list of agents iJ. Finally, ireqm and lprom are the request message 
and the proposition message respectively. They are specific to each protocol. 

The properties claimed to hold for these two protocols are the following: 

- Data confidentiality: only the owner of the agent can extract the offers. 

- Non-repudiability: a shop cannot repudiate an offer once it has been received 
by the owner of the agent. 

- Forward privacy: (for P2) none of the identities of the shops can be extracted. 

- Strong forward integrity: except the last one, offers cannot be modified. 

- Publicly verifiable forward integrity: (for PI only) anyone can verify the in- 
tegrity of a list of offers. 

- Insertion resilience: no offer can be inserted between two previous offers. 



- Truncation resilience: the list of collected offers can be truncated only at an 
offer whose author colludes with the attacker. 

Note that forward privacy only means that no one can extract the identity 
of the shops by looking only at the list of offers. This does not mean that the 
identity of shops cannot be inferred by other means as described above. 

The idea proposed by Asokan, Giilcii and Karjoth for ensuring insertion 
resilience, truncation resilience and a stronger form of forward integrity than 
the one proposed by Yee is to add unforgeable dependencies between offers, 
creating what they call a chaining relation: 

- The agent starts with a hash of the message made of the identity of the first 
server to be visited iB, salted with some random number lk: lHash {| Agent B, 
Nonce k|} 

- Then, within its offer, signed with its private key, each shop must add a hash 
of the message made of the previous offer iM together with the next server lC 
to be visited: lHash {|M, Agent C|}. 

The complete definition of ichain B ofr A L C is as follows for PI: 
sign B {|Crypt (pubK A) (Nonce ofr), Hash {jhead L, Agent C|}[} 

and as follows for P2: 

-flCrypt (pubK A) (sign B (Nonce ofr)), Hash {|head L, Agent C|}|} 

where lhead L denotes the previous offer collected by the agent and isign is the 
signature function defined by isign B X = {|Agent B, X, Crypt (priK B) (Hash 
X)|}. The start of the chaining relation, lanchor, is defined as a particular case 
of ichain by lanchor A n B = chain A n A (cons nil nil) B. 

Hence, if someone wants to modify or insert an offer, for the chaining relation 
to be preserved, he must be able to modify as well all the following offers, which 
is made a priori impossible by asking the shops to sign their offers with their 
private keys. The two remaining possible attacks are the deletion of the offers 
between two offers made by two colluding shops (or the same shop if the agent 
goes twice to the same malicious shop) or the deletion of all the offers (denial- 
of-service attack), and the addition of fake offers. So, a shop cannot even modify 
its own offer unless it colludes with another shop visited later (which may be the 
same) but, in this case, it must delete all the intermediate offers. For limiting 
this difficult deletion/truncation problem, Asokan, Giilcii and Karjoth suggest a 
few solutions like adding several next shops instead of just one. 

In our formalization, we do not need to include the salt random numbers 
used in [2] since the spy is not able to infer the content of encrypted messages 
if he does not know the inverse of the keys used for encrypting them (lanalz 
function) . 

We can know present the formal definitions of the requests and propositions: 

reqm A r n I B = {|Agent A, Number r, cons (Agent A) (cons (Agent B) I), 
cons (anchor A n B) nil[} 



prom B ofr A r I L J C = {|Agent A, Number r, app (J, del (Agent B, I)), 
cons (chain B ofr A L C) L|} 

In the request, iA and iB (the first server to be visited) are added to the 
itinerary ll. In the proposition, iB is deleted from ll and a new list of servers lJ 
is added. 

6 Correctness of PI and P2 

For proving the strong forward integrity, the insertion resilience and the trunca- 
tion resilience, wc need to define what is a valid chaining relation: 

inductive "valid A n B" intros 

Req: "cons (anchor A n B) nil G valid A n B" 

Prop: "L G valid A n B 

=> cons (chain (next_shop(head L)) ofr A L C) L G valid A n B" 

And to formalize the corresponding attacks, we use the following functions: 

- iith(L,i) is the ii+1-th clement of iL. 

- irepl(L,i,M) is the list iL with its ii+1-th clement replaced by iM. 

- iins(L,i,M) is the list iL with iM inserted before the ii+1-th element of iL. 

- itrunc(L,i) truncates the li first elements of iL. 

The three properties are then easily proved by induction on lvalid: 

lemma strong_f orward_integrity : "[L G valid A n B; Sue i < len L; 

repl(L,Suc i,M) G valid A n B] M = ith(L,Suc i) " 

lemma insertion_resilience : "[L G valid A n B; Sue i < len L] 

=> ins(L,Suc i,M) ^ valid A n B" 
lemma truncation_resilience : "[L G valid A n B; Sue i < len L; 

cons M (trunc(L,Suc i)) G valid A n B] =>■ shop M = shop (ith(L,i))" 

For the data confidentiality, wc first prove that both a request m and an offer 
lofr are guarded by the private key of the agent's owner. Then: 

lemma req_notin_spies : "[evs G pi; req A r n I B G set evs; A $5 bad] 

=> Nonce n analz (spies evs)" 
lemma pro_notin_spies : "[evs G pi; pro B ofr A r I L J C G set evs; 

A ^ bad; B ^ bad] => Nonce ofr $5 analz (spies evs)" 

We also proved that requests and offers are not known by other agents (and 
not only by the spy as it is commonly done). Although this is not very compli- 
cated, this requires to extend the Isabelle libraries. 

For the non-rcpudiability, we proved that the signature scheme is secure: 

lemma "[evs G pi; A bad; sign A X G parts(spies evs)] 
=> 3 B Y. Says A B Y G set evs k sign A X G parts Y" 

We would like to point out that, although it was the first time we used 
Isabelle, thanks to the way we formalized PI and the power of the Isabelle 
tactics (although, sometimes, we would like them to be less sensitive to some 
syntactical aspects), once PI has been proved, it took us only a few minutes to 



formalize and prove P2 by essentially changing the definition of ichain. It is easy 
to experiment with changes in message formats. 

7 Conclusion and future work 

Approaches based on proof assistants like Paulson's inductive approach [2T| in 
Isabelle |18| are known to require much effort, typically several days or weeks, 
for certifying a protocol. Establishing general protocol-independent theorems like 
the ones we presented in this paper helps to reduce this development time and 
also to get a better understanding of protocol problems. To go further, automated 
theorem provers could be used or tactics developed for automatically proving the 
conditions of these theorems. In the case of our guardedness condition, it is clear 
from the examples we give that the proofs follow similar patterns. This is why 
we expect to define Isabelle tactics for doing that and also for proving the unicity 
lemmas automatically. 

Finally, we did not take into account in our formalizations what some au- 
thors call the "oops" rule [53], that is, the fact that, for some protocols like 
Yahalom, a particular session is not affected by the compromise of other ses- 
sion keys. But, instead of adding the oops rule and doing the proof again, one 
may look for conditions under which a secrecy property without oops implies 
the same property with oops. This would provide another important and useful 
protocol-independent result. 
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